JEP 486: Permanently Disable the Security Manager

AuthorSean Mullan & Alex Buckley
OwnerSean Mullan
TypeFeature
ScopeSE
StatusIntegrated
Release24
Componentsecurity-libs / java.security
Discussionsecurity dash dev at openjdk dot java dot net
EffortL
DurationL
Relates toJEP 411: Deprecate the Security Manager for Removal
Reviewed byAlan Bateman, Mark Reinhold, Stuart Marks
Endorsed byAlan Bateman
Created2024/08/19 23:43
Updated2024/12/19 20:05
Issue8338625

Summary

The Security Manager has not been the primary means of securing client-side Java code for many years, it has rarely been used to secure server-side code, and it is costly to maintain. We therefore deprecated it for removal in Java 17 via JEP 411 (2021). As the next step toward removing the Security Manager, we will revise the Java Platform specification so that developers cannot enable it and other Platform classes do not refer to it. This change will have no impact on the vast majority of applications, libraries, and tools. We will remove the Security Manager API in a future release.

Goals

Non-Goals

Motivation

The Security Manager has been a feature of the Java Platform since its first release. It is based upon the principle of least privilege: Code is untrusted by default, so it cannot access resources such as the filesystem or the network, and developers place trust in specific code by granting it permission to access specific resources. In theory, this can protect machines and applications against code that contains accidental vulnerabilities or was crafted with malicious intent. In practice, however, the permission scheme is so complex that the Security Manager has always been disabled by default, and its use is exceedingly rare.

Despite the fact that the Security Manager is disabled by default, the least-privilege model induces extraordinary complexity in the Java Platform libraries. From networking, I/O, and JDBC, to XML, AWT, and Swing, the libraries must implement the least-privilege model in case the Security Manager is enabled:

The OpenJDK Core Libraries Group devotes significant time and energy to reviewing every change to any of these methods. Every new API must be designed, and its implementation carefully audited, with the least-privilege model in mind. However, only a tiny number of applications actually enable the Security Manager. To make matters worse, most of them, in our experience, blindly grant all permissions to their code, thereby giving up the benefits of the least-privilege model.

We therefore deprecated the Security Manager, for removal, in Java 17 via JEP 411 (2021). In addition to terminally deprecating the Security Manager API and related APIs, we also revised the JDK to issue warning messages when the Security Manager is enabled. These changes were designed to prepare users and developers for the removal of the Security Manager in a future release.

Deprecating the Security Manager had hardly any impact

JDK 17 and later releases enjoyed wide adoption as developers and enterprises upgraded from JDK 8 and JDK 11. We have seen hardly any discussion in the Java ecosystem about the warnings that these releases issue when enabling the Security Manager. This indicates that the Security Manager is almost completely irrelevant to current Java developers. We appear to have been correct when we said, in JEP 411, that,

"In the quarter-century since the Security Manager was introduced, adoption has been low”,

and,

"In summary, there is no significant interest in developing modern Java applications with the Security Manager."

Since the release of JDK 17, the maintainers of some of the handful of frameworks and tools that supported the Security Manager have removed support for it; these include Derby, Ant, SpotBugs, and Tomcat. The maintainers of Jakarta EE removed the requirement for EE applications to support the Security Manager. We are not aware of any new projects that support the Security Manager.

Moving forward

The vast majority of applications, libraries, and tools do not require the Security Manager, do not recommend the Security Manager, do not use the Security Manager, and do not work if other code uses the Security Manager. It is time for the Java ecosystem to take the next step and stop using the Security Manager entirely.

We will therefore revise the specification of the Security Manager so that developers cannot enable it, and we will revise the specifications of other Java Platform libraries so that they do not delegate resource-access decisions to it. We will leave a minimal version of the java.lang.SecurityManager class in place for compatibility with the few applications, libraries, and tools that still use it. We will remove this class in a future release.

Removing the Security Manager will improve Java security

We believe that the vast majority of Java developers would prefer to see the OpenJDK Core Libraries Group focus on practical security features needed by Internet-facing applications. The above revisions to the specification will allow us to remove the implementation of the Security Manager from the JDK codebase, together with thousands of permission checks and privilege elevations. That, in turn, will make more contributor time and energy available for other work such as

Most contemporary security threats involve malicious data, against which the Security Manager is ill equipped to defend. Removing the implementation of the Security Manager will make more contributor time and energy available for security features that defend against malicious data directly, such as:

Sandboxing Java code

Sandboxing is the ability to run some Java code with different permissions than other code. The permissions for each piece of code are determined by a security policy, which is enforced by the Security Manager. Code running with restricted permissions, such as untrusted or potentially hostile code, is often referred to as being in a sandbox.

Historically, the Security Manager was used to sandbox applets; we never recommended it for sandboxing entire applications. Java applications should be sandboxed in the same way as native applications, using technologies outside the JDK such as containers, hypervisors, and OS mechanisms such as the macOS App Sandbox or the Linux seccomp feature. Like the Security Manager, these technologies can restrict how applications use local and remote resources; they can, e.g., prevent code from accessing the network to exfiltrate data. Unlike the Security Manager, however, they have wide adoption and are relatively easy to learn and use effectively.

Intercepting calls to the Java Platform API

A small number of applications have used the Security Manager not to enforce a security policy but, rather, as a means to intercept calls to the Java Platform API. In the absence of a security policy and permission checking, calls to the Java Platform API are no longer a security concern as such. Truly malicious code has innumerable ways to bypass the Security Manager's interception of API calls. Nonetheless, some applications find interception useful, particularly to block calls to methods such as System::exit.

We designed, prototyped, and evaluated a variety of mechanisms that an application could use instead of the Security Manager to intercept calls to the Java Platform API. We found that the use cases were too broad, and the requirements too diffuse, to support the introduction of such a mechanism. The OpenJDK Core Libraries Group is unwilling to maintain an arbitrary number of API interception points with ill-defined requirements across the JDK in perpetuity.

In most cases, we found that issues that seemed to need interception could be adequately addressed outside the JDK, using techniques such as source code modification, static code analysis and rewriting, or agent-based dynamic code rewriting at class load time. See the Appendix for an example of an agent that uses dynamic code rewriting to intercept calls to System::exit.

The Security Manager in older Java releases

The Security Manager will continue to be available in every release prior to JDK 24. Application deployers who are wary of adopting new releases because they value stability above all else are unlikely ever to upgrade to JDK 24, and therefore will never be affected by changes to the Security Manager in JDK 24 or subsequent releases.

Description

In JDK 24, we will:

Enabling the Security Manager in JDK 24 is an error

In JDK 24, you cannot enable the Security Manager at startup, nor can you install a custom Security Manager during run time.

How to determine if an application enables the Security Manager

If you are not sure whether your application enables the Security Manager, here are some things you can do to find out:

Rendering the Security Manager API non-functional

The Security Manager API consists of:

We are not removing these methods from Java 24; rather, we are degrading their behavior. They will, as appropriate, return null or false, or pass through the caller's request, or unconditionally throw a SecurityException. The full set of behavioral changes is available here.

In addition to changing the behavior of the API, we will:

Changes elsewhere in the Java Platform API

Approximately 1,000 constructors and methods in the Platform are specified to throw SecurityException if the Security Manager is enabled and appropriate permissions have not been granted. They span 264 classes, 73 packages, and 25 modules. For example, java.base has 640 methods specified to throw SecurityException.

In Java 24, we will revise the specifications of all such constructors and methods to remove mentions of SecurityException since that exception will now never be thrown. The complete list of revised constructors and methods is available here.

Here is an example of the specification change for a constructor in java.io.FileOutputStream (struck through text is deleted):

public FileOutputStream(String name)
         throws FileNotFoundException

Creates a file output stream to write to the file with the specified
name. A new FileDescriptor object is created to represent this file
connection.

First, if there is a security manager, its checkWrite method is
called with name as its argument.

If the file exists but is a directory rather than a regular file,
does not exist but cannot be created, or cannot be opened for any
other reason then a FileNotFoundException is thrown.

Implementation Requirements:
   Invoking this constructor with the parameter name is equivalent
   to invoking new FileOutputStream(name, false).
Parameters:
   name - the system-dependent file name.
Throws:
   FileNotFoundException - if the file exists but is a directory
   rather than a regular file, does not exist but cannot be created,
   or cannot be opened for any other reason
   SecurityException - if a security manager exists and its checkWrite
   method denies write access to the file.
See Also:
   SecurityManager.checkWrite(java.lang.String)

Advice to maintainers of libraries that support the Security Manager

A small number of libraries were designed to use the Security Manager if it is enabled. These libraries typically employ two idioms:

In JDK 24, where a Security Manager is never enabled, the System::getSecurityManager and AccessController::doPrivileged methods behave as they did in JDK 17 when a Security Manager was not enabled:

  • System::getSecurityManager returns null,
  • The SecurityManager::check* methods throw SecurityException, and
  • The six AccessController::doPrivileged methods execute the given action immediately.

Accordingly, the small number of libraries that call these methods will run on JDK 24 without change. However, we strongly recommend that new releases of these libraries do not call these methods, which we will remove in a future release.

A very small number of libraries use advanced parts of the Security Manager API to implement a custom execution environment. For example, a library might call AccessController::checkPermission to enforce its own permission model, or call Policy::setPolicy to make custom Security Managers treat certain resources as off-limits. These methods are non-functional in JDK 24 in order to provide an execution environment that disallows access to all resources by default. We will remove them in a future JDK release.

Future Work

We are not removing any classes or methods from the Java Platform API in Java 24. In a future release we will remove the Security Manager APIs that we deprecated in Java 17. In future releases we may, further, deprecate and remove additional classes and methods in the java.lang and java.security packages.

  • We are not deprecating SecurityException now because it is used elsewhere in the JDK in situations that are unrelated to the Security Manager, despite the fact that its specification says, "Thrown by the security manager to indicate a security violation". Here are examples of its (mis)use:

    • java.lang.ClassLoader::defineClass throws SecurityException if the name of the class being defined starts with "java.".

    • java.lang.reflect.Constructor::setAccessible throws it if invoked on the Constructor object for a constructor of java.lang.Class.

    • java.util.java.JarInputStream throws it when signed JAR entries are signed incorrectly.

    After reexamining these misuses, we may deprecate SecurityException in a future release.

  • In a future release we will deprecate Permission and related classes such as BasicPermission, PermissionCollection, and Permissions, and also subclasses of Permission outside of the java.security package, such as java.lang.RuntimePermission, java.net.NetPermission, and java.lang.reflect.ReflectPermission.

  • In a future release we will deprecate PrivilegedAction, PrivilegedExceptionAction, and PrivilegedActionException. We did not deprecate these classes in Java 17 because they appear in method signatures of javax.security.auth.Subject, a class unrelated to the Security Manager. In Java 18, we added replacement methods to javax.security.auth.Subject that do not use the Privileged* classes. We will eventually remove both the old methods and the Privileged* classes.

Various early Java Platform features were designed around a vision of mobile objects. They used serialization to move code and data between JVMs, and assumed applications would enable the Security Manager to defend against maliciously serialized objects. This vision did not gain any traction. Given the fundamental flaws in serialization and the minimal use of the Security Manager, we have either already removed these features or else we plan to do so:

Separately, the javax.xml APIs allow Java source code to be embedded directly in XSLT and XPath documents as extension functions. This feature is enabled by default but, historically, it was disabled when running with the Security Manager. We will disable this feature by default in a future release, as part of a broader effort toward stricter XML processing.

Testing

The breadth of the Security Manager API and the depth of its support in the JDK codebase is reflected in the approximately 4,000 tests developed for it since JDK 1.0. They fall into three categories:

Permanently disabling the Security Manager will make these tests irrelevant since the functionality will no longer be supported and the concept of a sandbox will no longer exist. Including tests, we will delete over 50,000 lines of code.

Alternatives

The numerous check* methods in the Security Manager API always throw an exception so as to avoid unconditionally permitting operations that formerly required a permission check, and thus might not have been permitted. This may be inconvenient for application maintainers, who may have to take some corrective action. An alternative would be to have these methods always succeed, but that would allow an application to operate insecurely without notifying the maintainer.

Risks and Assumptions

Appendix

An agent is a Java program that can alter the code of an application while the application is running. Agents achieve this by transforming the bytecodes of methods when classes are loaded, or by redefining classes after they have been loaded.

Here is an agent that blocks code from calling System::exit. The agent declares a premain method that is run by the JVM before the main method of the application. This method registers a transformer that transforms class files as they are loaded from the class path or module path. The transformer rewrites every call to System.exit(int) into throw new RuntimeException("System.exit not allowed").

The transformer reads and writes bytecodes in class files using the Class-File API, which is a preview feature in JDK 23. See the java.lang.classfile package for details. The agent's source code imports the Class-File API and other Java APIs with module import declarations, which are also a preview feature in JDK 23.

import module java.base;
import module java.instrument;

public class BlockSystemExitAgent {
    /*
     * Before the application starts, register a transformer of class files.
     */
    public static void premain(String agentArgs, Instrumentation inst) {
        var transformer = new ClassFileTransformer() {
            @Override
            public byte[] transform(ClassLoader      loader,
                                    String           className,
                                    Class<?>         classBeingRedefined,
                                    ProtectionDomain protectionDomain,
                                    byte[]           classBytes) {
                if (loader != null && loader != ClassLoader.getPlatformClassLoader()) {
                    return blockSystemExit(classBytes);
                } else {
                    return null;
                }
            }
        };
        inst.addTransformer(transformer, true);
    }

    /*
     * Rewrite every invokestatic of System::exit(int) to an athrow of RuntimeException.
     */
    private static byte[] blockSystemExit(byte[] classBytes) {
        var modified = new AtomicBoolean();
        ClassFile cf = ClassFile.of(ClassFile.DebugElementsOption.DROP_DEBUG);
        ClassModel classModel = cf.parse(classBytes);

        Predicate<MethodModel> invokesSystemExit =
            methodModel -> methodModel.code()
                                      .map(codeModel ->
                                             codeModel.elementStream()
                                                      .anyMatch(BlockSystemExitAgent::isInvocationOfSystemExit))
                                      .orElse(false);

        CodeTransform rewriteSystemExit =
            (codeBuilder, codeElement) -> {
                if (isInvocationOfSystemExit(codeElement)) {
                    var runtimeException = ClassDesc.of("java.lang.RuntimeException");
                    codeBuilder.new_(runtimeException)                    
                               .dup()
                               .ldc("System.exit not allowed")
                               .invokespecial(runtimeException,
                                   "<init>",
                                   MethodTypeDesc.ofDescriptor("(Ljava/lang/String;)V"),
                                   false)
                               .athrow();
                    modified.set(true);
                } else {
                    codeBuilder.with(codeElement);
                }
            };

        ClassTransform ct = ClassTransform.transformingMethodBodies(invokesSystemExit, rewriteSystemExit);
        byte[] newClassBytes = cf.transform(classModel, ct);
        if (modified.get()) {
            return newClassBytes;
        } else {
            return null;
        }
    }

    private static boolean isInvocationOfSystemExit(CodeElement codeElement) {
        return codeElement instanceof InvokeInstruction i
                && i.opcode() == Opcode.INVOKESTATIC
                && "java/lang/System".equals(i.owner().asInternalName())
                && "exit".equals(i.name().stringValue())
                && "(I)V".equals(i.type().stringValue());
    }
}

You must package the agent in a JAR file and specify it via the -javaagent option when starting the application:

# Compile the agent into the agentclasses directory, enabling preview features for JDK 23
$ javac --enable-preview --release 23 -d agentclasses BlockSystemExitAgent.java

# Create JAR file manifest in agent.mf
$ cat > agent.mf << EOF
Premain-Class: BlockSystemExitAgent
Can-Retransform-Classes: true
EOF

# Create the agent JAR (Note there is a period after -C agentclasses)
$ jar --create --file=BlockSystemExitAgent.jar --manifest=agent.mf -C agentclasses .

# Run application with the agent JAR, enabling preview features for JDK 23
$ java --enable-preview -javaagent:BlockSystemExitAgent.jar -jar app.jar